libp2p spec
詳細なspecとか
2.1 The client-server model
サーバ・クライアントモデルのように役割固定ではなく、どのノードもdial, listenどちらも出来るようにしている
2.2 Categorizing the network stack protocols by solutions
OSI参照モデルのように1レイヤー1プロトコルではなく、役割によってプロトコルをカテゴライズしている
同じ役割のプロトコル(OSI参照モデルで言う同じレイヤーのプロトコル)を同時に扱うことが出来る
Peer Discovery(後述)という同じ役割をするが、最初に接続するnodeはbootstrap listを、ローカルのnodeはmDNSを、他のnodeはDHT(Distribution Hash Table; 分散ハッシュテーブル)を使うなど
3 Requirements and considerations
3.1 Transport agnostic
libp2pは特定のtransportプロトコルに依存しないようにしている
例
code: example
# IPFS over TCP over IPv6 (typical TCP)
/ip6/fe80::8823:6dff:fee7:f172/tcp/4001/ipfs/QmYJyUMAcXEw1b5bFfbBbzYu5wyyjLMRHXGUkCXpag74Fu
/protocol/addressやportなどのstring のように / で各プロトコルの情報をつなげていくイメージ
3.2 Multi-multiplexing
リソースを節約したりコネクションの確立を簡単にするため(TCPやUDP portのような)一つのportだけを利用して、複数のプロトコルを多重化(multiplex)している
3.3 Encryption
libp2p上のコミュニケーションは
encrypted(暗号化あり)
signed(暗号化なし、署名あり)
clear(暗号化なし、署名なし)
に分類される。
デフォルトではencrypted推奨だが、ハイパフォーマンスが求められる環境ではそれ以外も選択肢としてある
暗号化はTLSのような仕組みを使っている。
3.4 NAT traversal
NAT越えにはICE(Interactive Connectivity Establishment)のような仕組みを使っている
3.5 Relay
NAT越え出来なかったときのためにリレーを実装する必要がある
3.6 Enable several network topologies
ネットワークのトポロジには
Centralized: 通常のWebアプリケーションのように固定のLocation(サーバ)が決まっているもの
Unstructred: P2Pネットワークのようにトポロジがランダムに決まるもの
Structured: トポロジが明示的にきまっているもの
Hybrid: UnstructredとStructuredの組み合わせ
のように異なるものが色々あるので、異なるroutingやpeer discoveryのメカニズムが必要
3.7 Resource discovery
レコード(record)を通してresource discoveryを行う
レコードは署名、タイムスタンプがあり特定の用途の有効性を示す(ephemeral validity)ために使われるもの
レコードは場所(location)やリソースの有効性を保存している
3.8 Messaging
最小のレイテンシや複雑なトポロジでの通信のためにMultiCastやPubSubのような方法を検討している
3.9 Naming
4 Architecture
理解、テストしやすいように小さいコンポーネントで構成される
各ピアはdialer, listenerどちらとしても振る舞うことが出来、コネクションは再利用される
code: architecture
┌─────────────────────────────────────────────────────────────────────────────────┐
│ libp2p │
└─────────────────────────────────────────────────────────────────────────────────┘
┌─────────────────┐┌─────────────────┐┌──────────────────────────┐┌───────────────┐
│ Peer Routing ││ Swarm ││ Distributed Record Store ││ Discovery │
└─────────────────┘└─────────────────┘└──────────────────────────┘└───────────────┘
Peer Routing
メッセージを送る時のroutingにどのpeerを使うかどうかを決定するメカニズム
Swarm
ストリームを開く(opening a stream)部分全てを扱う
protocol muxing, stream muxing, NAT traversal, connection relaying, multi-transport
Distributed Record Store
DNSのような役割
レコードの保存や配布(distribute)をする
レコードはシグナリング(signaling), リンクの確立、ピアやコンテンツを知らせる等の目的で他のシステムで使われるentry
Discovery
他のピアの発見や同定(identifying)をする
4.1 Peer Routing
DHTからどのピアにメッセージをroutingすればよいかのインターフェースを持つ
keyを受け取って PeerInfo を返す
具体的な実装としてはKademlia DHTやmDNSなどが考えられる
4.2 Swarm
4.2.2 Protocol Muxer
1つのソケットを使ってNAT越えのコストなどを節約するため、プロトコルの多重化はアプリケーションレベルで行う
6 Interfaces
6.2 Peer Routing
key を受け取って PeerInfo を返す
例
kad(Kademlia)
6.3 Swarm
6.3.1 Transport
現状実装があるのはほぼTCPベースのもの(TCP, WebRTC, WebSocketなど)のみ
utp(BitTorrentとかで使われているUDP上でTCPっぽい通信をするやつ)もあるらしい
例
TCP
multiple transports
TCP only, TCP+WebSocket, WebSocket onlyの3つのnode間での接続
共通のプロトコルがあるnode間のみ接続出来る
6.3.2 Connection
6.3.3 Stream Muxing
一つのprotocol内で複数のstreamを使える
例
mplex
6.4 Distributed Record Store
6.5 Peer Discovery
見つかったpeerの PeerInfo を返す
例
bootstrap node
peerを探すために最初に接続する
mDNS
ローカルマシン内の仮想環境などに接続する
kad(Kademlia)
DHT上をランダムウォークして新しいnodeに接続する
7.1 Communication Model - Streams
ネットワークレイヤーはピアへの接続をハンドルして双方向ストリームを提供する。
ユーザーは新しくストリームを開く(NewStream)、ストリームハンドラを登録する(SetStreamHandler)ことが出来る。
その後、ユーザーは自由にメッセージプロトコルを実装することが出来る。これらはピア同士のプロトコルを作るのを楽にする。
NewStreamはHTTPクライアントでリクエストを作るようなもの
SetStreamHandlerはHTTPサーバでURLハンドラを登録するようなもの
7.2 Ports - Constrained Entrypoints
2015年のインターネットでは複数ポートはもちろん、1つのポート間でさえNATのせいで通信するのが難しかった。
IPFSは(TCP, UDP, WebSocket, WebRTCなどの)1つのポートしか使わない。
7.3 Transport Protocols
IPFSはどの通信プロトコルの上でも動作する。ipfs-addr(multiaddr)が通信を記述する。
実際の通信の接続は各addrのプロトコルのライブラリに移譲する。
7.4 Non-IP Networks
NDNやXIAというプロトコルの上でもうごく（らしい）
7.5 On the wire
リンク
公式
仕様
実装